Field of the Invention
This invention generally relates to database management systems and more specifically to efficient management of multi-user, on-demand, distributed relational databases at a plurality of database processing resources, each of which may contain a plurality of databases.
Description of Related Art
Over the last few decades interest in databases has been increasing. Databases have been growing in size. A variety of database management systems have been developed to manage such databases. As the size of a database has increased, there has been and continues to be a requirement for providing resources of increased capability to operate such database management systems.
The requirement for increased resources previously has been met by adding or substituting storage resources and by the addition of or the replacement of existing processor resources with new storage and/or processor resources with greater capabilities. Consequently over time the total cost of ownership (“TCO”) that includes hardware, facility and power costs has been increasing and has been threatening to impact the benefit of the database versus the TCO of that database.
The above-identified U.S. Pat. No. 8,224,860 provides an alternative database management system that limits the rate of increase of the total cost of ownership. This system operates as a distributed database processing system. Users connect to the system through transactional nodes (also called “transaction engines”). Each of one or more storage managers (or “archival nodes”) stores all the data and metadata for the entire database. Increases in the database size are compensated by increasing the storage capacity of such storage managers without an upgrade of the hardware that implements the storage manager. However, a transaction engine at any given time must store and process only that data and metadata as required for responding to a query. Operations are performed asynchronously by means of messages transmitted and received between the various transaction engines and storage managers. Transaction engines do not require large memories and the processing of information is simplified, so the resources of a transaction engine are not subject to any significant change as a database grows over time. Consequently, the TCO of such a database management system can be relatively insensitive to changes in database size. Historically, this database management system has been employed to implement management and control over a single, large database with multiple locations, or nodes, from which multiple users access the database.
More recently “cloud computing” has been applied in environments where a provider enables a number of different users to access to a number of different “small” databases. In addition, new server configurations now are available that have somewhat limited resources, but that operate with significantly reduced power, space and related costs. A typical server includes multiple data processors that operate with resources that are limited in comparison to more sophisticated data processing systems. Each server data processor can manipulate multiple databases. In these systems the multiple data server data processors operate collectively. Moreover, each database must be available or “on-line” at all times even during periods during which the database operates with little or no activity. The operational state of such server data processors and databases can be monitored and a database can be made inactive to free up resources. However, when a database is made inactive in such an environment, it is “off-line” and a user must wait for the database to be restored before operations can begin. This introduces a delay which, in many situations and environments, cannot be tolerated. Also, at times operations of a given database in a specific server data processor may tax the available resources to the detriment of processing other databases as, for example, when a user submits a request that initiates a series of rapid transactions. This can also introduce an unacceptable delay.
What is needed is a database management system that is operable in a cloud computing environment, that can disable an inactive database to optimize the operation of a server and can compensate for an allocation of significant resources to one database on the server to the detriment of other databases, all transparently to the user and automatically without direct intervention by administrative personnel.